Deployment
This page describes how to run a configured solution and what to do when it doesn’t work as expected. It covers the Deployment page of the Studio, a troubleshooting overview, the detailed path planning troubleshooting for Bin Picking Studio (BPS), and what to send to Photoneo support. Everything applies to BPS and Locator Studio (LS), except where a section says otherwise.
A few terms used on this page:
Deploy – start a fully configured solution, so that your application runs.
Production mode – the robot program sends the action requests. This is how the application runs in production.
Simulation mode – you send the action requests yourself from the Deployment page. The real robot doesn’t have to be connected.
Object status – how far a localized object got in the path planning pipeline. The visualizer shows it as the object’s color (BPS).
Inspector – a tool on the Deployment page that shows the details of path planning for one object (BPS).
Deployment page
You can deploy a solution in three ways:
On the Solutions page, click the Ready flag of the solution.
In the solution configuration wizard, click the Deployment shortcut at the bottom.
On the Deployment page, select the solution in the list of solutions that are ready for deployment.
The Deployment page with a deployed BPS solution.
While a solution is deployed, the page has buttons to stop the deployment and to restart it. Before a restart, the Studio checks that the solution is still complete.
In LS solutions, the visualizer shows only the scan and the localized objects, without the robot and its environment. In Layer Localization solutions, the point cloud is colored by segment.
Deployment modes
When you deploy a solution, a dialog asks you to choose the deployment mode: Production or Simulation.
Choosing the deployment mode.
The modes differ in who sends the action requests:
Production – the Action Request Client in the robot program (the main program) sends the requests. The action request toolbar only offers the Scan request.
Simulation – you send the requests from the action request toolbar, which offers all basic requests. Use it to try out and tune the application without the real robot. Any request from the Action Request Client in this mode ends with an error.
Note
Hand-eye vision systems need data from the Robot State Server. To use a hand-eye vision system in Simulation mode, connect the real robot.
Hardware diagnostics
The Deployment page shows the state of the connections to the robot and the sensors:
Action Request Client – the Action Request channel between the robot program and the vision controller.
Robot State Server – the Robot State channel. Through it, the vision controller receives the current joint positions and TCP pose of the robot. BPS needs this channel; for LS it is optional.
Sensor status – one indicator for each vision system’s sensor. Hover over it to see the state.
Each indicator shows one of these states:
CONNECTED (green) – the connection works. The Action Request Client can send requests, and the Robot State Server receives robot data.
WARNING (orange) – the component reports a problem.
DISCONNECTED (red) – there is no connection. The Action Request Server waits for the client to connect, and the Robot State Client keeps trying to connect to the robot.
For more about the channels, see Robot communication overview. If a connection doesn’t work, see Troubleshooting network connections.
Deployment action request toolbar
The action request toolbar is a group of widgets on the Deployment page. Each widget sends one action request. In Production mode only the Scan widget is available. In Simulation mode the toolbar offers the basic BPS action requests:
Initialization – initialize a vision system with the Start and End poses of the bin picking routine.
Change scene state – change the active virtual model of the environment.
Change localization bounding box – change the active bounding box for localization.
Scan – scan, localize objects and compute trajectories.
Trajectory – get a trajectory for a picked object.
Initialization
The Initialization widget.
Select the vision system with the radio buttons at the top.
Enter the Start and End poses, in degrees or radians. Each vision system has its own poses.
The arrows between the poses copy one pose to the other (Start → End or End → Start).
The keyboard arrow keys change the selected joint value. The preview updates right away.
The eye icon shows or hides a transparent robot in that pose in the visualizer.
The buttons in the bottom right corner copy the poses to the clipboard and paste them into another vision system.
Click Send. Clear sets all joint values to zero.
Note
The browser remembers the last used poses for each solution and fills them in when you deploy the solution again. This includes poses that the robot sent in an Initialization request.
Change scene state
The Change scene state widget.
The widget lists the scene states of the deployed solution. Click a scene state identifier to make it active.
Change localization bounding box
The Change localization bounding box widget.
The widget lists the vision systems of the deployed solution with the IDs of their bounding boxes. Click a bounding box identifier to make it active for that vision system.
Note
The identifier X turns off all bounding boxes. Localization then searches the whole scene.
Scan
The Scan widget.
Click a vision system identifier to scan with that vision system. The widget can also:
force a full scan, also when a fast scan would be done otherwise
run localization on the last scan, without a new scan (the Localize on the last scan request)
Trajectory
The Trajectory widget.
Click a vision system identifier to get a trajectory for that vision system.
Deployment console
The console lists current and past events of the application.
The Deployment console.
Each message has the format TIMESTAMP - LOG LEVEL - MESSAGE [VISION SYSTEM ID]:
TIMESTAMP – when the event happened. You can show or hide the milliseconds.
LOG LEVEL – how important the message is:
INFO – progress of the application
WARN – a possible problem
ERROR – an error in the application
FATAL – a severe error that stops the application
MESSAGE – a short description of the event.
VISION SYSTEM ID – the vision system the event belongs to, if any.
To save the messages, see Downloading support logs.
Visualizers
Main visualizer
The main visualizer shows the robot cell in real time: the localized objects and, when the Robot State Server is connected, the movement of the real robot.
The main visualizer on the Deployment page.
It has these widgets:
View – choose one of the predefined viewpoints.
Camera – choose the camera mode. Orbit keeps the base horizontal, Trackball rotates freely in all directions.
Visibility – show or hide the environment objects, sensors, and the links of the robot and the gripper.
Axis – show the coordinate frames of the environment objects, sensors, and the links of the robot and the gripper.
Measure – pick two points in the scene to get the distance between them.
Point Cloud – show or hide the point cloud, and change its point size and color.
Scan – the type of the last scan (full or fast), the number of points of the last full scan, and its vision system.
Joint States – the current joint values of the connected robot.
Bounding Boxes – show the localization bounding box of a vision system, if it has one.
In BPS, the color of each localized object shows its object status, and it changes as the object goes through path planning. Click an object to see its details and open the Inspector.
Object status chart
The chart shows the share of each object status among all localized objects. Hover over a color to see the number of objects with that status and their percentage.
The Object status chart with the count and percentage of Ready to pick objects.
Cycle timer
The cycle timer shows how fast the application runs. A cycle is the time between two consecutive Scan or Trajectory requests for the same vision system; you choose which request type is measured. The time is measured on the vision controller, at the moment it sends the response to the robot.
The cycle timer with the Trajectory cycle times of two vision systems.
The chart shows up to the last 20 cycles as bars. The height of a bar is the cycle time in seconds.
Each vision system has its own color. Requests that ended with an error are red.
Click the vision system buttons above the chart to show or hide its cycles.
Hover over a bar to see the vision system and the exact time. For a failed Trajectory request it also shows the error message.
The average cycle time is calculated from the visible bars only, so hiding a vision system changes it.
Troubleshooting overview
Find your problem below. Each item points to the section that describes it in detail. If nothing here helps, contact Photoneo support, see Support logs.
The robot can’t connect to the vision controller
Check the connection status. The Deployment page shows the state of the Action Request Client and the Robot State Server. See Hardware diagnostics.
Test the network connection. Use the Test connection button in the Robot interface section of the Network page, and go through the checklist for a DISCONNECTED state. See Troubleshooting the robot interface.
Check the network configuration. The robot interface settings and the IP ranges you must not use are described in Robot interface and Banned IP ranges.
Understand the communication channels. The robot and the vision controller talk over the Action Request channel and, in BPS, the Robot State channel. See Communication channels.
Look up the error code. Connection and communication procedures in the robot program return an error code. Network-related codes such as Communication error (3) and Timeout (5) are listed in General errors from Connection and Communication procedures.
The sensor isn’t found or isn’t connected
Check the sensor status. The Deployment page shows a status indicator for each vision system’s sensor, and the deployment raises a FATAL error if it can’t connect. See Troubleshooting the sensor interfaces.
Check the IP configuration. The sensor interface and the sensor must be on the same subnet. The valid combinations are listed in Troubleshooting the sensor interfaces, and the interface settings in Sensor interfaces.
Check the sensor on the PhoXi page. The PhoXi page lists the sensors and their status, and lets you connect to a sensor and trigger a scan. See PhoXi page.
Calibration is inaccurate or fails
Follow the best practices. Use diverse robot poses, cover the whole bin with calibration points and avoid small calibration balls. See Tips and Troubleshooting.
Point cloud offset or ball not recognized. The same section explains a point cloud offset in the Z-axis and a calibration ball that is visible on the texture but not recognized.
Check the robot setup. The base frame offset, the tool center point and the Robot State Server are described in Robot.
Check the result. See Verification.
Use a custom calibration scanning profile. In difficult scanning conditions the default profile may not recognize the calibration tool well. See Calibration scanning profile.
No object is found or objects are rejected
Look up the error code. The codes No object found (202) (BPS), No object found, Detection running (502), No object found, Detection stopped (503), All objects rejected, Detection running (504) and All objects rejected, Detection stopped (505) (LS) each come with a troubleshooting hint. See No object found and Errors from Locator action requests.
Check the bounding box. Localization only searches inside the active bounding box, and the box must be activated before the Scan request. See Bounding boxes and Runtime.
Check the constraints. Objects outside a constraint are rejected. See Constraint - Angle, Constraint - Object dimensions, Constraint - Layer depth and Constraint - Points above localized layer. Each constraint has the setting Exclude rejected objects from the Localized objects counter, which controls whether rejected objects are counted in the Get vision system status request.
Check the request timeout. In CAD Localization and Layer Localization, an error code is sent to the robot if no suitable object is found within the Get objects request timeout [s]. See Advanced settings.
Improve the scan. A custom scanning profile optimized for your application gives the best scanning results. See Localization scanning profile.
Path planning fails or the gripper collides (BPS)
Find the cause in the Inspector. The object status shows how far each object got in the path planning pipeline, and the Inspector on the Deployment page shows the details. See Performance troubleshooting.
Go through the object status guide. Each failure status, such as Gripper volumetric model in collision or Trajectory planning failed, has its own section. See Object status guide.
Check waypoint and trajectory statuses. See Waypoint status and IK result and Trajectory status.
Collisions with the scan. Reflections in the scan can cause false collisions. See Impact of scan quality on collision checking and Common collision situations.
Look up the error code. See Path planning failed (201).
Save the scans. Turn on automatic saving of scans when path planning fails, so you can analyze the situation later. See Saved scans.
Performance troubleshooting
This section applies to BPS only. It explains the object statuses, the Inspector, and how to fix path planning problems.
The Inspector showing the trajectory planned for an object.
Object status
The visualizer on the Deployment page shows the CAD models of all localized objects inside the point cloud. As an object goes through path planning, its color changes to show its status. Path planning ends with either a success or a failure status.
An object can usually be picked in many ways: different gripping points, invariances and tool points. The Studio tries them in the order of the sorting criteria until one succeeds or all fail. Different ways can fail at different stages. The object status always shows the furthest stage that any of them reached.
Bin picking pipeline stage statuses
The statuses below are listed in the order in which an object reaches them.
Color |
Status |
Description |
|---|---|---|
|
New object |
A newly localized object, or an object from the previous run that moved more than the pose tolerance. Path planning starts from scratch. |
|
Object from the previous run |
An object from the previous run that moved less than the pose tolerance. Its old path plan, or part of it, is checked in this run. |
|
Path plan from the previous run is not valid |
A waypoint or trajectory from the previous run is no longer valid (it now collides with the scene), or the object failed path planning in the previous run. Path planning starts from scratch. |
|
Path plan from the previous run is valid |
All waypoints and some or all trajectories from the previous run are still valid. The missing trajectories are computed in this run. |
|
All waypoints computed |
The IK of all waypoints was computed. |
|
Trajectory planned |
All trajectories were planned. |
|
Ready to pick |
The object is ready to be picked. |
|
Object being picked |
The trajectory for this object was sent to the robot. The object is picked in the current cycle. |
Note
You set the pose tolerance in the Preserve path plan section of the solution settings. For symmetrical objects, also set Object symmetry axis.
Failure statuses
The failure statuses are listed in the order of the path planning stages where they can occur. How to fix each of them is described in Object status guide.
Color |
Status |
Description |
|---|---|---|
|
No gripping points defined |
The object of this vision system has no gripping point. |
|
Object occluded from scanner position |
Other objects hide this object from the scanner. Only when Pick only unoccluded objects is Enabled (not the default). |
|
Grasping angle rejected |
In the Grasp waypoint, the angle between the Z-axis of the tool point and the gripper angle reference vector is larger than allowed. |
|
Gripper in collision in grasp pose |
In the Grasp waypoint, the gripper collides with the scan or with another localized object. Only when Gripper collision checking type is Volumetric (the default). |
|
Waypoint computation failed |
One of the waypoints has no valid IK solution. |
|
Trajectory planning failed |
One of the trajectories could not be planned. |
Inspector widget
The Inspector shows everything about the path planning of one object in one place. It can also play the planned motion of the robot. Use it to find out why path planning fails and what to change in the solution.
Click a localized object in the visualizer. A red box appears around it, and a window shows:
ID – the unique ID of the object.
Overlap – how much of the object’s CAD model overlaps with the point cloud, in percent.
Status – the object status, also shown by the object’s color.
The window has a Show Inspector button if the object got at least to the grasping angle check and path planning for it has finished, with success or failure.
The details of a selected object, with the Show Inspector button.
General information
Click Show Inspector to open the Inspector at the bottom of the visualizer. Depending on the object status, it has one or more of these tabs: Grasp invariances, Waypoints and Trajectories.
These values are always shown:
GP ID – the ID of the gripping point of this grasp.
GP Inv – the invariance of the gripping point.
TP Inv – the invariance of the tool point.
∡Z – the angle between the Z-axis of the tool point and the Gripper angle reference vector. If it is larger than the Angular threshold between the tool point and the reference vector, the grasp is rejected.
When the robot is shown, the bottom right corner shows its current joint values. With Gripper collision checking type set to Volumetric (the default), the Gripper model selector in the bottom left corner switches between the gripper’s STL model and its volumetric model.
The Inspector. A – a tab with its values (here Waypoints); B – Gripper model selector; C – values that are always shown; D – current joint values; E – Close button.
When you click another object, the Inspector switches to it, if the Inspector is available for that object’s status. The Inspector stays open until you click Close in its upper right corner.
Grasp invariances
Available for the statuses Grasping angle rejected, Gripper in collision in grasp pose and Waypoint computation failed.
Use this tab to check the grasp pose. It has two sliders:
Grasp Invariance – steps through the invariances of all gripping points. For Grasping angle rejected it shows all invariances. For the other statuses it shows only the invariances within the angle limit.
Grasp Configurations – steps through the computed IK configurations. Only for Waypoint computation failed, for invariances whose IK failed because of a collision, and only with the Standard (Iterative) IK solver.
The tab also shows:
Status – the waypoint status. On this tab it is always the Grasp waypoint.
IK result – the result of the IK computation for this invariance.
Time – how long the computation took.
Gripper collision – how much of the gripper volume is in collision, in percent. Only with the Volumetric collision checking type. If the value is above Gripper collision sensitivity, the exact value isn’t shown.
What the visualizer shows depends on the status:
Grasping angle rejected – nothing.
Gripper in collision in grasp pose – the gripper in the grasp pose.
Waypoint computation failed – also the robot, if its IK in the grasp pose was computed, or failed because of a collision.
Red dots show the waypoints of the bin picking routine. Black lines join them where the trajectories would be planned.
The Grasp invariances tab, with the gripper’s volumetric model shown.
Waypoints
Available for the statuses Gripper in collision in grasp pose, Waypoint computation failed, Trajectory planning failed, Ready to pick and Object being picked.
Use this tab to check the waypoints of the bin picking routine. For the Grasp waypoint it shows the same as the Grasp invariances tab. It has two sliders:
Waypoints – steps through the waypoints. They belong to the invariance selected on the Grasp invariances tab.
Configurations – steps through the computed IK configurations. Only for Waypoint computation failed, for the waypoint whose IK failed because of a collision, and only with the Standard (Iterative) IK solver. Earlier waypoints show only their successful configurations; later waypoints weren’t computed.
The tab also shows:
Name – the name of the path stage in the grasping method.
Status – the waypoint status.
IK result – the IK result of the selected configuration. If it is In collision, the colliding pair is named here and shown in transparent red.
Time – how long the computation took.
The visualizer shows the gripper in each waypoint, and the robot too if its IK was computed, or failed because of a collision. Red dots and black lines show the waypoints and the trajectories between them.
The Waypoints tab. In the Deapproach waypoint the gripper collides with the right wall of the bin, as the IK result says.
Trajectories
Available for the statuses Trajectory planning failed, Ready to pick and Object being picked.
Use this tab to check the planned trajectories. Its Trajectories slider moves the robot along the trajectories, as the real robot would move. If planning failed, the last slider position belongs to the trajectory that failed.
The tab also shows, for the trajectory (segment) at the slider position:
Segment – the trajectory between two consecutive waypoints.
Status – the trajectory status.
Time – how long the computation took.
Planned segments are green lines through small blue dots, which are the points of the trajectory. A segment that failed is a black line between its two waypoints.
The Trajectories tab. The trajectory from the Deapproach waypoint to the End waypoint failed.
Troubleshooting path planning
Start with the object status guide, then use the waypoint and trajectory status tables to find the fix.
Object status guide
No gripping points defined
Reason: The object of this vision system has no gripping point.
Fix: Define at least one gripping point for the object.
Object occluded from scanner position
Only when Pick only unoccluded objects is Enabled (not the default).
Reason: Other objects hide this object from the scanner.
Fix: Wait until the objects on top are picked, or turn the setting off if it doesn’t suit your application.
Grasping angle rejected
Reason: In the Grasp waypoint, the angle between the Z-axis of the tool point and the gripper angle reference vector is larger than allowed.
Shown grasps: All of them.
Waypoint status: In the Grasp waypoint, all grasps exceed the Angular threshold between the tool point and the reference vector, so they have the status Grasping angle rejected.
How to check:
Open the Inspector for the object.
Go to the Grasp invariances tab.
Move the Grasp Invariance slider through the invariances.
Look at ∡Z. In all grasps it is above the Angular threshold between the tool point and the reference vector.
Fix: See Grasping angle rejected in Waypoint status and IK result.
Gripper volumetric model in collision in grasp pose
Only when Gripper collision checking type is Volumetric (the default).
Reason: In the Grasp waypoint, the gripper collides with the scan or with another localized object.
Shown grasps: Only those within the allowed grasping angle.
Waypoint status: In the Grasp waypoint, all grasps exceed the Gripper collision sensitivity, so they have the status Gripper volumetric model in collision in grasp pose. The other waypoints have the status Not computed, but the Inspector still shows the gripper pose in them.
How to check:
Open the Inspector for the object.
Go to the Grasp invariances tab.
Move the Grasp Invariance slider through the invariances.
Look at Gripper collision. In all grasps it is above the Gripper collision sensitivity.
Fix: See Gripper volumetric model in collision in grasp pose in Waypoint status and IK result.
Waypoint computation failed
Reason: One of the waypoints has no valid IK solution.
Shown grasps: Only those within the allowed grasping angle.
Waypoint status: The IK failed in one of the waypoints; the waypoint status and IK result say why. The IK is computed for the Grasp waypoint first, then for the other waypoints from Start to End. The waypoints after the failed one have the status Not computed.
With the Volumetric collision checking type, some (but not all) grasps can exceed the Gripper collision sensitivity in the Grasp waypoint, with the status Gripper volumetric model in collision in grasp pose (see Gripper collision). For those grasps, no IK was computed.
How to check:
Open the Inspector for the object.
Go to the Grasp invariances tab.
Move the Grasp Invariance slider through the invariances. For a grasp whose Grasp waypoint status isn’t OK, the Waypoints tab isn’t relevant, because no other waypoint was computed. Check its Status and IK result to find the cause.
At least one grasp has the Grasp waypoint status OK, but none has all its waypoints computed. Select a grasp with status OK and go to the Waypoints tab. Find the waypoint that failed and check its Status and IK result.
The invariance selected on the Grasp invariances tab is also the Grasp waypoint on the Waypoints tab.
Fix: See Waypoint status and IK result.
Trajectory planning failed
Reason: One of the trajectories could not be planned.
Shown grasps: Only the one that has all waypoints computed.
Waypoint status: All waypoints of this grasp have the status OK.
How to check:
Open the Inspector for the object.
Go to the Trajectories tab.
Move the Trajectories slider through the segments.
The last slider position belongs to the segment that failed. Check its Status to find the cause.
Fix: See Trajectory status.
Waypoint status and IK result
Waypoint status |
Meaning |
IK result |
Fix |
|---|---|---|---|
Grasping angle rejected Only for the object status Grasping angle rejected. |
No IK was computed, because the angle between the tool point Z-axis and the Gripper reference vector is above the threshold. |
No configuration |
|
Gripper volumetric model in collision in grasp pose Only with the Volumetric collision checking type (the default). |
No IK was computed, because the gripper volume in collision is above the Gripper collision sensitivity. |
No configuration |
If collision checking is set up correctly, the gripper really would collide. The object can be picked later, after the objects around it are picked. If you think the collision check is wrong:
|
Not computed |
No IK was computed, because the IK of an earlier waypoint failed. The order is: the Grasp waypoint first, then the others from Start to End. |
No configuration |
Fix the earlier waypoint first. |
Unreachable |
No IK configuration was found within the time limit. The waypoint is out of the robot’s reach, or the timeout is too short. |
No configuration |
|
No valid joint configuration |
IK configurations were found, but none is valid. The IK result says why. |
In collision – the robot, gripper or picked object collides. Gripper volumetric model in collision – the IK was computed, but the gripper volume in collision is above the Gripper collision sensitivity. Only with the Volumetric collision checking type, and only in custom waypoints between the Approach and Deapproach waypoints. |
In collision:
Gripper volumetric model in collision: if you think the collision check is wrong, check the scan quality. |
OK |
A valid IK configuration was found. |
OK |
– |
Trajectory status
Trajectory status |
Meaning |
Fix |
|---|---|---|
Joint planning failed |
A joint trajectory segment could not be planned. |
|
Linear planning failed |
A linear trajectory segment could not be planned. |
|
Cartesian threshold failed |
In a linear segment, a joint rotates by more than 0.3 rad between two consecutive trajectory points. |
Preview the segment and find the point where this happens. Possible causes:
Set or adjust the joint limits. In case 3, you can also lower the Linear sampling step. The trajectory points are then closer together, but the real robot may move more slowly. |
Joint trajectory is too long |
The segment was planned, but has more than 100 points. Only when Path planner is Standard (not the default). |
Change the grasping method so that the two waypoints of this segment are closer together. |
Linear trajectory is too long |
The segment was planned, but has more than 100 points. |
Increase the Linear sampling step, or change the grasping method so that the two waypoints of this segment are closer together. |
End position mismatch |
All segments were planned, but the joint configuration in the End waypoint differs from the End pose sent in the Initialization request. |
Adjust the joint limits so that the robot can reach the End waypoint only in the configuration of the End pose. |
Computed |
The segment was planned. |
– |
Impact of scan quality on collision checking
Path planning turns the latest scan into a volumetric model and checks collisions against it. Collision checking is only as good as the scan. Reflections from the bin or from shiny objects appear as points floating in the air, and the robot may seem to collide with them.
If you see such reflections in your scans, raise the Minimum required size of a volumetric model segment to filter out the small segments, or ask Photoneo support for help.
Common collision situations
These situations often make the waypoint IK fail:
In collision (scan <-> gripper_base) in the Approach waypoint – the Approach waypoint is too close to the Grasp waypoint, so close to the object and the scan. Reflections above the object then collide with the gripper. Move the Approach waypoint further from the Grasp waypoint.
In collision (picked_object <-> scan) in the Deapproach waypoint, with the scan of the picked object or other objects – with Collision checking with the picked object attached to the gripper set to Enabled (the default), the picked object is attached to the gripper in the Deapproach waypoint. The distance from the Grasp waypoint to the Deapproach waypoint must be larger than the biggest dimension of the picked object.
In collision (picked_object <-> scan / bin) in the Deapproach waypoint, with a wall of the bin – the Deapproach waypoint is straight above the Grasp waypoint, and the attached picked object touches the bin wall in the scan or in the bin model (which may be thicker than the real wall for safety). Make the Deapproach lean away from the walls: use the Start/End waypoint as the origin of its relative offset, and put the Start/End waypoint above the center of the bin. See Grasping methods.
Support logs
This section lists what to send to Photoneo support when you ask for help.
Contacting support
Send your request to support@photoneo.com. Describe the problem and attach the files listed below.
When a fatal error occurs, the Studio shows the dialog An error occurred. It asks you to download the support logs and, if the problem persists, to create a support ticket at www.photoneo.com/Help-Center with the support logs attached.
Downloading support logs
The menu in the top right corner of every Studio page has two download options:
Download support logs – the Studio builds a log package and downloads it. The An error occurred dialog has the same button.
Download deployment console logs – downloads only the messages of the deployment console.
The Studio menu. Red frames: Download deployment console logs and Download support logs.
Saved scans
Scans of the situation where the problem happened help support reproduce it. The Studio can save the last set of scans automatically, for example after a fatal internal error, when no object is found or when path planning fails. Turn on the events you need before the problem happens, in Automatic saving of scans.
Solution export
Export the solution as a .pbcf file with Export on the Solutions page. See Solutions page.
If Automatic Backup is turned on for the solution, the Studio also exports it on each deployment after a configuration change, to ~/Desktop/Backup on the vision controller.